MongoDB : 是一个 ,高性能 , 无模式 , 文档性 , 目前NoSQL中最热门的数据库 , 开源产品 , 基于C++开发 , 是NoSql数据库中功能最丰富的 , 最像关系性数据库的非关系性数据库。

特点 :

1，面向集合文档的存储 ,存储格式Bson(json的扩展)。格式自由 , 数据格式不固定 ,生产环境下修改结构都可以不影响程序运行。

2，具备强大查询语句（对象查询HQL） , 基本覆盖SQL语言所有能力。

3，完整索引支持 , 支持查询计划，支持复制和自动故障转移。

4，支持二进制数据及大型对象(文件)的高效存储。

5，可以集群，使用分片集群提升系统扩展性。

概括起来就是 :MongoDB适用存储海量 , 不敏感 , 有要求一定查询性能的数据对格式要求不规则的数据。

MongoDB的不使用的场景 :

对事务要求较高的系统 以及对SQL要求比较高的系统如实时性分析系统。

涉及到复杂的 , 高度优化的查询方式的系统，以及数据量不多结构规整的需求也不何时选用MongoDB。

MongoDB的持久化机制就是利用文件和数据库日志系统来实现。

文件：MongoDB通过将数据保存在本地文件中来实现持久性。它会将增删改查等操作全部记录在本地文件中，这样即使服务器发生故障，只要按照先前记录的内容来恢复操作，也可以恢复到原来的状态，不用担心数据丢失。

日志系统：MongoDB还采用了两种文件日志系统，一种是副本集的复制日志，用来从主服务器同步数据到从服务器，备份时，也可以把主服务器上的数据同步回从服务器；另一种是复制集的操作日志，用于恢复副本集，也即复制回主服务器。

MongoDB还提供了一个命令行工具mongodump，它可以制作出一个可以离线恢复的备份文件，以备物资不测时需要使用。

总之，MongoDB的持久化机制为用户提供了安全可靠的服务，使用MongoDB不用再担心数据的丢失。

在1.8版本之后开始支持journal，就是我们常说的redo log，用于故障恢复和持久化。

在2.0之后的版本，journal都是默认打开的，以确保数据安全。

journal工作原理

journal文件是以“j._”开头命名的，且是append only的，如果1个journal文件满了1G大小，mongodb就会新创建一个journal文件来使用，一旦某个journal文件所记载的写操作都被使用过了，mongodb就会把这个journal文件删除。使用 smallfiles 这个运行时选项可以将journal文件大小减至128M大小。

1，启动服务后，MongoDB请求操作系统将Data file（磁盘文件）映射到Shared view（内存），此时并不将数据加载到Shared view中，而MongoDB的数据实在需要的时候再加载到Shared view的。2，而后再请求操作系统将Shared view映射到Private view（内存），之后MongDB对数据的读写操作都是直接操作的Private view。

3，MongoDB写操作：Private view变脏以后，根据journalCommitInterval的设置，将在一定时间后将写操作往Journal file中复制，这个过程称为“group commit”。Journal file中记录的是原生的操作，这些原生的操作可以使MongoDB完成以下操作： 文档的插入/更新； 索引修改；命名空间文件的修改；这些原生操作告诉了Journal file数据变化发生在Data file的什么位置。至此，MongoDB上发生的写事件可以被认为是安全的了，因为这些写操作已经被记录在了Journal file上，即使服务器掉电了，在下次启动MongoDB时，Journal file上的写操作将会被重演。

4，接下来，Journal file中记录的写操作会应用在Shared view上：默认每隔60秒，MongoDB请求操作系统将Shared view刷新输出到Data file。数据就被写入到数据文件了。这时MongoDB还会将Journal file中已输出到Data file的写操作删除掉。

最后，MongoDB还会例行地如一开始一样，将Shared view映射到Private view，以保持一致性。

Mongodb 提供的 Master-Slave 策略，是分布式系统最开始的冗余策略是一种热备策略。Master-Slave 架构一般用于备份或者做读写分离，一般是一主一从设计和一主多从设计。Master-Slave 由主从角色构成：Master ( 主 )可读可写，当数据有修改的时候，会将 Oplog 同步到所有连接的Salve 上去。Slave ( 从 )只读，所有的 Slave 从 Master 同步数据，从节点与从节点之间不感知。局限性：

数据不一致问题。根本原因在于只有 Master 节点可以写，Slave 节点只能同步 Master 数据并对外提供读服务，这是一个异步的过程。虽然最终数据会被 Slave 同步到，在数据完全一致之前，数据是不一致的。所以读写分离的结构只适合特定场景，对于必须需要数据强一致的场景是不合适这种读写分离的。

人为切换。Master-Slave 的角色只有Master 节点，Slave 节点，是静态配置的，无法自动切换角色。

单点。用户只能写 Master 节点，Slave 节点只能从 Master 拉数据；Slave 节点只和 Master 通信，Slave 之间相互不感知，这种好处对于 Master 来说优点是非常轻量，缺点是：系统是单点。

Replica Set 副本集模式

Replica Set 是 mongod 的实例集合，包含三类节点角色：Primary（ 主节点 ），Secondary（ 副本节点 ），Arbiter（ 仲裁者 ）。Primary（ 主节点 ）：只有主节点可读可写，Primary 接收所有写请求，然后把数据同步到所有 Secondary 。一个 Replica Set 只有一个 Primary 节点，当 Primary 挂掉后，其他 Secondary 或者 Arbiter 节点会选举一个 Primary 节点，这样就又可以提供服务了。读请求默认是发到 Primary 节点处理，如果需要故意转发到 Secondary 需要客户端修改一下配置。Secondary（ 副本节点 ）：数据副本节点，当主节点挂掉的时候，参与选主。Arbiter（ 仲裁者 ）不存数据，不会被选为主，只进行选主投票。使用 Arbiter 可以减轻在减少数据的冗余备份，又能提供高可用的能力。

MongoDB 的 Replica Set 副本集模式特点：

解决性能和容量瓶颈一般来说优化有两个方向：

纵向优化是传统企业最常见的思路，持续不断的加大单个磁盘和机器的容量和性能。横向优化通俗来讲就是加节点。业务上要划分系统数据集，并在多台服务器上处理，做到容量和能力跟机器数量成正比。那么，实际情况下，哪一种更具可行性呢？自然是分布式技术的方案，纵向优化的方案非常容易到达物理极限，横向优化则对个体要求不高，而是群体发挥效果。MongoDB 的 Sharding 模式就是 MongoDB 横向扩容的一个架构实现。Sharding 模式角色Sharding 模式下按照层次划分可以分为 3 个大模块：

单 Shard 集群是有限的，但 Shard 数量是无限的，Mongo 理论上能够提供近乎无限的空间，能够不断的横向扩容。首先，要选一个字段（或者多个字段组合也可以）用来做 Key，这个 Key 可以是你任意指定的一个字段。我们现在就是要使用这个 Key 来，通过分片策略（Sharding Strategy）算出发往哪个 Shard 上。输入Sharding Key ，按照Sharding Strategy 计算出一个值，值的集合形成了一个值域，按照固定步长去切分这个值域，每一个片叫做 Chunk ，每个 Chunk 出生的时候就和某个 Shard 绑定起来，这个绑定关系存储在配置中心里。所以，MongoDB 用 Chunk 做了一层抽象层，隔离了用户数据和 Shard 的位置，用户数据先按照分片策略算出落在哪个 Chunk 上，由于 Chunk 某一时刻只属于某一个 Shard，所以自然就知道用户数据存到哪个 Shard 了。

Sharding 模式下数据读取过程：mongos 作为路由模块其实就是寻路的组件，写的时候先算出用户 key 属于哪个 Chunk，然后找出这个 Chunk 属于哪个 Shard，最后把请求发给这个 Shard ，就能把数据写下去。读的时候也是类似，先算出用户 key 属于哪个 Chunk，然后找出这个 Chunk 属于哪个 Shard，最后把请求发给这个 Shard ，就能把数据读上来。实际情况下，mongos 不需要每次都和 Config Server 交互，大部分情况下只需要把 Chunk 的映射表 cache 一份在 mongos 的内存，就能减少一次网络交互，提高性能。本质上 Sharding Strategy 是形成值域的策略而已，MongoDB 支持两种 Sharding Strategy：

Hashed Sharding把 Key 作为输入，输入到一个 Hash 函数中，计算出一个整数值，值的集合形成了一个值域，按照固定步长去切分这个值域，每一个片叫做 Chunk ，这里的 Chunk 则就是整数的一段范围而已。优点：计算快，随机好均衡性好。缺点是性能差需要所有Shard 参与。Range ShardingRange 的方式本质上是直接用 Key 本身来做值，形成的 一个值域。

优点：对排序列举场景非常友好，因为数据本来就是按照顺序依次放在 Shard 上的，排序列举的时候，顺序读即可，非常快速；

缺点：容易导致热点，举个例子，如果 Sharding Key 都有相同前缀，那么大概率会分配到同一个 Shard 上，就盯着这个 Shard 写，其他 Shard 空闲的很，却无法使用；

Shard（Replica Set）集群个数多了，即使一个或多个 Shard 不可用，Mongo 集群对外仍可以 提供读取和写入服务。因为每一个 Shard 都有一个 Primary 节点，都可以提供写服务，可用性进一步提升。